Technical Field
This application relates generally to computer-based multi-user interactions, such as educational games, and more particularly, in one aspect, to the automatic validation of the logic employed in such interactions, and handling in-game changes in the participants and/or parameters of such interactions.
Background
Computer-based multi-user interactive environments, such as educational multi-player online games, are well-known. One requirement for such environments (and software in general) is that, to the extent possible, they must avoid such situations as divide-by-zero errors, numeric overflow, and “endless loops”, while at the same time performing within known memory and computation time limits. A divide-by-zero error occurs when a mathematical division is performed with a denominator of zero, causing unexpected results and/or program crashes. Numeric overflow occurs when a numerical operation is performed, but the result cannot be represented by the allocated bytes in memory. The stored result is therefore incorrect, leading to subsequent data issues, system instability or unavailability, or other issues. Similarly, an endless loop may cause a set of instructions to be repeated endlessly, causing the program to hang indefinitely until it crashes or is forcibly stopped. Endless loops involving memory write operations may also cause the program to consume all available system resources. Even without endless loops, the program cannot operate if it requires more memory or processing time than is available. This is especially important for multi-user environments where resource consumption increases with the number of users. The rate at which resource usage increases in a multi-user environment may be linear, or even exponential.
Another consideration for existing gaming products (e.g., those played in classroom settings) is their dependency on technology solutions that require labor-intensive, manual actions by users. Playing such games often requires the administrator (e.g., the instructor) to set up the game, configure the game parameters, and invite players (e.g., students) to participate long before the lecture starts. Any adjustment further delays execution of the game session and diminishes the probability that the session will be completed in the allotted time. For games that are conducted in a class session of limited time (e.g., 60 minutes), these maintenance/clerical tasks may consume roughly 20% of overall class time.
The execution of such an existing game during a classroom session—in which the instructor operates the game via a web-based platform—would proceed as follows. First, well before the start of the classroom session, an instructor would create a “new class” in the platform, and then create a list of specific names and email addresses for that class. This requires the instructor to compile a list (e.g., in a spreadsheet) of these names and email addresses beforehand, and then upload or type them into the platform to form the “new class.” Such an operation can require 15-20 minutes or longer to complete for typical class sizes of 50 players.
Next, the instructor configures the specific game session via a game configuration procedure. The game configuration may include configuring the parameters of the game, the number of rounds, or the length of time allotted for the game, and may also include associating a specific class with the game session. Once set, these parameters become fixed for the game session. This includes the class size, meaning that the number of players is fixed for the duration of the game. The platform then emails (or otherwise communicates to) each player identified as part of the class that will play the game with a player-specific unique link through which players join the session.
During gameplay, any alteration to the game configuration requires restarting a new, separate game session with those updates. Of course, this restart delays the entire session while changes are made, because any changes would entail proceeding through each of the aforementioned steps for game configuration. In the case of unannounced no-shows (e.g., a student deciding not to show up to the class session), or any players arriving late or leaving early, the game is prevented from progressing if the correct number of players (as specified during the configuration of the game) is not active in the session. But adding or removing players from the class requires that the game-session configuration for that class itself must also be updated. Regardless of the changes to parameters, time, or players, for example, new links may need to be sent to players to re-invite them to the correct game session. At minimum, the game needs to be restarted from the beginning. This restart interrupts the flow and extends the overall duration of the game. Typically this process may require an additional 10-20 minutes to complete.
As a result, changes to game sessions may be avoided in practice. This can limit the capability of players to play at all (e.g., a late arrival is simply excluded), or may curtail the ability to alter the environment so that players experience the full range of game situations. For example, modifying the time allotted for the game, or changing parameters that alter game outcomes, may be disallowed. Furthermore, technical stability and reliability issues (such as program crashes due to numerical overflow or excessive computation or memory) during a limited time game play session with an audience (e.g., students) must be avoided. Such technological considerations make it difficult for educators/managers to adopt such games in education or live management demonstration sessions.